Endianness is an arbitrary convention of byte order, required when integers or any other data are represented with multiple bytes. For example, integers larger than 255 require at least two bytes of storage. Similar, text strings encoded in unicode UTF-16 or UTF-32 respectively require two bytes and four bytes of storage for each character. In such situations, there are different ways those bytes can be arranged in memory or in transmission over some medium. By convention, the two orders are called “Little Endian” and “Big Endian”.
“Little Endian” means that the low-order byte (the least significant byte or LSB) of the number is stored in memory at the lowest address, and the high-order byte (most significant bit or MSB) at the highest address. (Thus, the little end comes first.) For example, a 4 byte Longlnt (long integer) comprising:                Byte3 Byte2 Byte1 Byte0will be arranged in memory as follows:        
Base Address+0Byte0Base Address+1Byte1Base Address+2Byte2Base Address+3Byte3Processors employing Intel's® ubiquitous IA32 architecture (the processors employed in most personal computers, notebooks, servers, etc.) use “Little Endian” byte order.
“Big Endian” means that the high-order byte of the number is stored in memory at the lowest address, and the low-order byte at the highest address. (The big end comes first.) The previous 4-byte Longlnt would then be stored as:
Base Address+0Byte3Base Address+1Byte2Base Address+2Byte1Base Address+3Byte0Motorola® processors and IBM® PowerPC™ processors, such as those employed in Apple® Macintosh™ computers, and Sun® SPARC™ processors use “Big Endian” byte order, among others.
Some processor architectures can be configured to operate in either little-endian or big-endian mode. These include Intel® processors having the IA64 architecture (e.g., Itanium®), ARM DEC Alpha, MIPS, PA-RISC and some IBM PowerPC® processor architectures. Such processors are called “bi-endian,” which denotes the capability to be configured to pass and store data in either big-endian or little-endian format.
Endianness has significant implications on software portability. For example, in interpreting data stored in binary format and using an appropriate bitmask, the endianness is important because different endianness will lead to different results from the mask. Additionally, proper endianness needs to be considered when writing binary data from software to a common format. For instance, saving data in the BMP bitmap format requires little endian integers—if the data are stored using big-endian integers then the data will be corrupted since they do not match the format. There are many other standard formats the employ specific endianness in a similar manner.
Usually, the problem with endianness can be easily dealt with at the application or operating system level. For example, endianness specified within a standard format is handled by merely adhering to the standard. Similarly, endianness within an application is typically self-contained, meaning that since that application is the only one dealing with the data, as long as the application is self-consistent with respect to endianness, there will be no problem, regardless of the native endian mode of the underlying processor.
The situation gets a little more difficult at the operating system (OS) level. Since an operating system has to “host” multiple applications, potentially having different endianness, the OS needs to provide a measure of consistency. This is generally handled by using application program interfaces (API's) with pre-defined endianness. Typically, the endianness employed by the OS will be in accordance with the underlying platform architecture the OS is ported to. Thus, an OS will be configured to operate using little endian byte order for processors that default to a corresponding little-endian mode (e.g., Microsoft Windows® on IA32 processors). Similarly, an OS will be configured to operate using big endian byte order for processors that default to a corresponding big-endian mode e.g., Mac OS X running on a Motorola Power Mac “G4” processor or IBM PowerPC “G5” processor.
The foregoing endian-specific operating systems create a problem for the platform vendor, particularly with respect to platform firmware. From the vendor's viewpoint, it would be advantageous to provide a single platform architecture that supports multiple operating systems in their native endian format. However, since current platform firmware is designed to operate in compliance with the processor architecture employed by the underlying platform processor(s), separate portings of operating systems are required to operate on endian-specific platforms.